COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	See also PLAN.RND for recent stuff from  RAND wrt the Planner project
C00003 00003	∂20-Mar-81  1558	GREINER at RAND-AI 	Things to do   
C00007 00004	∂Mailed to %RAND-AI KLAHR, DAVE 12:07 25-Mar
C00013 00005	∂22 Oct 1981 1126-PDT	<GREINER>	Forms
C00020 00006	∂TO WESCOURT@Rand-Ai 13:52 28-Oct
C00022 00007	∂TO DAVE, HENRY 16:39 30-Nov
C00024 ENDMK
C⊗;
See also PLAN.RND for recent stuff from  RAND wrt the Planner project
∂20-Mar-81  1558	GREINER at RAND-AI 	Things to do   

* 0) Mail off finances to Hiltrud
* 1) Send to %RAND-AI KLAHR, DAVE:
	RLL-1 manuals, MRS manuals and CORLL stuff
	Point out to them, also, changing RLL to relation based easier:
	Edit UA-GETPROP (and friends) - now discuss general non
	unary functions... these as easy
	(ie AnyUnitFunction subset of AnyUnitRelation, and ...)
  Even easier - just change UA-GETPROP & UA-PUTPROP, but that's cheating.
	Inheritance: from father - defn of LastName =
	(Composition LastName Father) - note problem is am own grandpa
  Another use of inheritance - creating a new unit.  
	I've build various mechanisms for this.
* 2) FTP files from SCORE to RAND-AI - editing several of them
	[BACKUPDIR now just my own, LISP source code files changed to
	correspond to <GREINER> if at RAND-AI, ...
* 3) Ask GORLIN if there are any (known) incompatibilites between RAND-AI
	and SCORE.
	What about Small Lisps - are there any around?
* 4) Ask RICK for more space. (at least another 1K needed; but I can expand 
	make-good-use-of any arbitrary amount.
	I did all the assignments suggested.  Enjoyed the visit.
* 5) Tell Doug my the primary source for the files will henceforth be RAND-AI.
	(IE stuff elsewhere (on SCORE) just backup.  I'll be able to return
	<CSD.LENAT> to you.)

### Real Work ###
KLUDGE simulation
(i) Get new specs to work - ala Units.
(ii) Describe class of phrases - as sequence of words.
	Currently just generalizations of individual words considered...
	later subsets of words.
(iii) Use other pointers (besides this "generalization"): 
	Rationalization, ...
(iv) Make creating new slots cheaper - as we'll need one for each noun,
	it seems.  Twiddle with single function for creation,
	one which "conses" together the relevant ToInitialize slots.
	(Note - this function, of course, invalidated when PossibleSlots...
	is changed.  In fact, this should be used in leiu of it.  Especially
	when compiled... Have it NOT include those which are "NoOp"s.)

Actually, finish up current RLL stuff first - 
  *  when invalidating stuff
  *  GetValue macros.
-------
∂Mailed to %RAND-AI KLAHR, DAVE 12:07 25-Mar
Several comments
0) The memos describing RLL-1, CORLL and MRS are now en route.

1) Two final points on the theme of inheritance.
i) Here's how RLL would address (actually sidestep) the
"inheritance from parent" problem you mentioned:
To specify that one's LastName is just your father's,
simply give the unit associated with the LastName type of slot the
HighLevelDefn of
	(Composition LastName Father)
[A bit of notation: This is the same as
	LastName:HighLevelDefn = (Composition LastName Father)]
Now suppose you ask for U:LastName.
RLL first sees if any value is primitively stored there,
returning such a value if it is found.
Otherwise it finds the value which fills U's Father slot; call it F.
[If there is no such U:Father value, the GetValue function returns,
and indicates it cannot determine the LastName of U.]
Otherwise, RLL now recursively tries to find F:LastName.
[The only problem with this solution arises if ever someone is
his own Grandpa... But that should cause grief anyway.]

A similar mechanism could be used to indicate that one of each chromosone
comes from the Father, and the other part from the Mother; etc.
Notice how this explicitness makes the whole notion of inheritance
less confusing; indeed almost vacuous.

ii) The other main (closely related) use of inheritance comes when a new
unit is being initialized --
ie, determining the initial values for various slots based on the unit's
"ancestry".  I've build various mechanisms for this.
(One each for the Epsilon, Subset and TypicalExample relations.)

2) Changing RLL to be relation-based
Soon after I left I realized that changing RLL to be
relation-based would be yet even easier than I'd imagined.
I'd only have to edit the primitive storing and retrieval functions -
(eg UA-GETPROP, UA-PUTPROP and friends).

[Of course this is sorta cheating, as RLL does not yet have a handle on these
primitives.  Eventually RLL will actually store
properties about these low level functions;
and those properties would have to be updated.]

Anyway, once done RLL could then handle general non-unary functions.
By considering slots to be a (now proper) subset of the set of
relations involving units,
we could now begin considering other storage/retrieval schemes.
See Mike Genesereth's "Metaphors and Models" paper (in AAAI#1))
for comments on managing numerous representational structures.

The MRS system is better able to achieve this desired versatility.
RLL will eventually become a "plug in" module to this system; and thereby
acquire access to MRS's store of implementation-related facts (concerning
p-lists, bit vectors, relational DBs, etc).
With this information RLL would be able to undergo such modifications "honestly".

-----
(Based on hopeless optimism if not facts,)
I hope these points have served to help, rather than hinder,
this presentation of the concept of an rll.
Let me know if there is anything else I can attempt to clarify.

3) RLL Bulletin Board
Phil is currently on the mailing list for this BB (which, who knows,
may one day say something.)
Should I add your name there as well, Dave?

Russ
∂22 Oct 1981 1126-PDT	<GREINER>	Forms
To: hiltrud at RAND-UNIX, JBERMAN at RAND-UNIX
cc: GREINER

Ms Johannsen -
	Thank you for the Expense Report forms you (or Jackie Berman)
sent.  I just received them yesterday.
	Unfortunately I ran out of consultant "Request for Payment" forms.
Could you send me some copies, at first convenience?  (I'm already one
payment request behind.)
	Thanks again,
Russ
-------

∂23 Oct 1981 11:55-PDT	hiltrud at RAND-UNIX	Re: Forms
To: Russell Greiner <GREINER at RAND-AI>
Cc: hiltrud at RAND-UNIX, JBERMAN at RAND-UNIX

Russell, I have a note here to call you regarding the consultant request
forms.  During the period April 1 through September 27 you were allocated
24 days, but you actually charged 26 (not including the 2 days you charged
for the last pay period which I changed to be in the new fiscal year.
during this new fiscal year we tentatively are going to allocate 26 working
days--23 for the period September 27 - March 31 and 23 for April 1 -
September 30.  This is tentative and has to be finalized by the project
leader and program director.  As soon as I have more information, I'll
contact you.

I suspect that some of your time charged started before April and
timesheets were turned in late and therefore the charges appeared between
April and September when we acutally should have charged some time in
March--but I will have it checked and let you know.

Yes, timesheets are in the mail.  Would you do our payroll department
and us too a favor and use Arabic numerals rather than Roman--thanks.


					hiltrud
                ---------------

-------
∂TO hiltrud at RAND-UNIX, JBERMAN at RAND-UNIX 14:06 23-Oct
Misc Comments
Hiltrud -

I was never told to work but 46/52-nds of a day each week.
Each of my 15 timesheets charged for two days of work during 
that two weeks period.
By the way, the first of these requests was for 
"work performed during period ending" March 22, and the last, 4 October.

In the future I will probably be too busy with other tasks to
spend this much time on Rand related things. 
(I have already discussed this with the other project members.)
As such I do not consider the 46-week-year too great a limitation.
However, I thus far have spent a great deal more time on this project 
(and Rand related work) than I have charged;
and I will be quite disappointed if my outstanding payment requests
are not honored.

Final points --
1) Thank you in advance for sending me the timesheets.
2) Yes, I will abandon the European date convention if that will mak
matters simpler for you.
I am curious, though, how you intend to disambiguate terms like
6/10/81 -- is this the 6th of October, or the 10 of June?

Russ

∂26-Oct-81  1529	hiltrud at RAND-UNIX 	Re: Misc Comments 
To: Russell Greiner <RDG at SU-AI>
Cc: hiltrud at RAND-UNIX, jberman at RAND-UNIX

Russ, you certainly shall get paid for time worked; basically, the dates
have changed because your timesheet for the pay period ending March 22 and
possibly the next one got into the system after April 1st.  Your allocated
days were from April 1 - September 30.  Any time worked after September 27
will be in the new fiscal year.  I was under the impression that your
project leader had notified you of the number of days you were allocated
during FY81.  When all budgets are worked for FY 82, out, I shall notify
you your allocated time.  Budgets should be finalized in a week or so.

As to usage of dates, here at Rand we use the American conventional way,
month, day, year rather than European way using day, month, year.  If you
send me a timesheet dated 6/10/81 I will read it as June 10, 1981.  I am
curious though, as to which country in Europe uses Roman numerals.

				hiltrud

Turns out it the style is Russian, not European per se.
∂TO WESCOURT@Rand-Ai 13:52 28-Oct
A puzzlement
Keith -
	While FTP and (assuming you do get this letter) mail seem to
work, I can't seem to TELNET to Rand-Ai from either SAIL or SCORE.
However I can TN to Rand-Unix, and telnet from there to Rand-Ai.
This make sense to you?

	By the way, the desired file was retrieved -- thanks for insuring
that that happened.

	Final point: The ARCHIVE help file is too vague when it mentions
the DIRECTORY.OWNER file.  Only thru trial and error did I learn it wanted
GREINER, ad not <GREINER>.  Perhaps an example could be included in that
help file (or someone's DIRECTORY.OWNER could be left visible to all who wish
to investigate.) 

	Thanks,
Russ
∂TO DAVE, HENRY 16:39 30-Nov
Of EMYCIN, Men
Dave, Henry -
	The EMYCIN manual has finally semi-arrived.  
A relatively small number of HPP memos have been produced, but are
being tightly guarded.
A larger quantity of (identical) CS reports are being produced,
and will be available with 3 to 5 weeks.

	If for some reason you desparately need access to this prize
publication, let me know, and I'll try to sneak one out.
(Note the Rosie "IF-," clause!)  Otherwise I'll see that you'se guys get a 
CS report sometime next month.

	How are things down there, by the way?  How Rick-independent are
your projects?  How do you stand wrt Gary Martins?
(I took the liberty of using you as apparently-unnecessary references,
by the way.  Thanks for your after-the-fact permission.)

	Russ